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(54) System and method for executing verifiable 
programs from trusted sources 

(57) A computer system includes a program execul- 
er that executes verifiable architecture neutral programs 
and a class loader that prohibits the loading and execu- 
tion of non-verifiable programs unless (A) the non-ven- 
fiable program resides in a trusted repository of such 
programs, or (B) the non-verifiable program is indirectly 
verifiable by way of a digital signature on the non-ven- 
fiable program that proves the program was produced 
by a trusted source. In the preferred embodiment, ven- 
fiable architecture neutral programs are Java bytecode 
programs whose integrity is verified using a Java byte- 
code program verifier. The non-verifiable programs are 
generally architecture specific compiled programs gen- 
erated with the assistance of a compiler. Each architec- 
ture specific program typically includes two signatures, 
including one by the compiling party and one by the 



programs with facility for using non-verlflable 

compiler. Each digital signature includes a signing party 
Identifier and an encrypted message. The encrypted 
message Includes a message generated by a prede- 
fined procedure, and is encrypted using a private en- 
cryption key associated wrth the signing party A digital 
signature verifier used by the class loader includes logic 
for processing each digital signature by obtaining a pub- 
lic key associated with the signing party, deciypting the 
encrypted message of the digital signature with that 
public key so as generate a decrypted message, gen- 
erating a test message by executing the predefined pro- 
cedure on the architecture specific program associated 
with the digital signature, comparing the test message 
with the decrypted message, and issuing a failure signal 
•rf the decrypted message digest and test message di- 
gest do not match. 
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(54) System and method for executing verifiable 
programs from trusted sources 

(57) A computer system includes a program execut- 
er that executes verifiable architecture neutral programs 
and a class loader that prohibits the loading and execu- 
tion of non-verifiable programs unless (A) the non-ven- 
fiable program resides in a trusted repository of such 
programs, or (B) the non-verifiable program is indirectly 
verifiable by way ot a digital signature on the non-ven- 
fiable program that proves the program was produced 
by a trusted source. In the preferred embodiment, veri- 
fiable architecture neutral programs are Java bytecode 
programs whose integrrty is verified using a Java byte- 
code program verifier. The non-verifiable programs are 
. generally architecture specific compiled programs gen- 
erated with the assistance of a compiler. Each architec- 
ture specific program typically includes two signatures, 
including one by the compiling party and one by the 



programs with facility for using non-verifiable 



compiler. Each digital signature includes a signing party 
identifier and an encrypted message. The enciypted 
message includes a message generated by a prede- 
fined procedure, and is enciypted using a private en- 
cryption key associated with the signing party. A digital 
signature verifier used by the class loader includes logic 
for processing eachdigital signature by obtaining apub- 
lic key associated with the signing party, decrypting the 
encrypted message of the digital signature with that 
public key so as generate a decrypted message, gen- 
erating a test message by executing the predefined pro- 
cedureon the architecture specific program assocated 
with the digital signature, comparing the test message 
with the decrypted message, and issuing a failure signal 
if the decrypted message digest and test message di- 
gest do not match. 
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Description 

prCams from trusted sources and for relus^g to executed other ,v)nw.teble programs. 
BACKGROUND OF THE INVENTION 

the user has explicitly granted it permission to use. „uses the ANPiogram to run less efficiently 

unfortunately, distributing executable programs .n ^.f^^^^^^T^j^^^ programs executed 
thanrtwou«i,«cou«taKeac^,antageda^^^^^ 

;r rSi^r :itrer : :.lZK TeX ™la.ent pr^^ cc^«ed in an 
ASLanguage. AMo.^^rom intn «n eouivalent ASProqram can be written. However, they n^y be 

of the most valuable features of an ANLanguage. „ k» ««.rfnrm«»d bv inteoritv non-verrfiable ASPrograms 

However, there are some legitimate (or legert) tasks that c^ be P5*^^,Jy ^^^^ ^thervrise violate 

the capability of executing integrity """^^^^^^^^^^.^ compilations require that the thircl party be 

it was compiled. MDr^«m nnmniler and comDilation method that enabies the 

Embodiments of the present bvention prov«Je ^" identify of who compiled the 

user of an ASProgram compiled from ^^'>"r^'''^^'ZZ^^uTaB^^ 
ANProgram.theidenti.yofthecorrespond«gA^^^^ 

I.eg^rS'^Ser^gT^^^^^^ 
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♦Ko* ^cc^ntiaiiv all leaitimate tasks can be performed, while preventing 

SUMMARY OF THE INVENTION 

^ «v»,.> Iter that executes verifiable architecture neutral programs, 
In suauTiarv. the preser,t invention .s a ^''^^ZZ^^Tnln^^^^^ ""less (A) the non-verlfiaWe 

and a class loader that prohibits the loading ° 1^°;^ '^^^^^^^ program is indirectly verifiable by 

prograr. resides in a trusted repository oi '^f^^^^'^J^^S^T^^^^^^ was produced by a trusted source. . 
way of a digrtal signature on the ^^^^ neutral program embodied In an object 

In the preferred embodiment, each ''ff^^^^'^l^^^^Zassoo\a^^ with that program. 

. the compiled, architecture specific code; .^^,„„,^hk:h sometimes there is rwl),infomriationidentilying the 
key. 

.,enera,.avai,able.trustedrepos«oryo,pub..en^^^^^^^^^^ 

pubticlys for the compiler and the tn^sted ^-P'''"^ P^'^,^^^^^ m tl?e object class to verHy that the 

object classes having non-verifiable programs can decw the ^ «'9 ^^^^ 
ob ect Class was created by a trusted party, -"^ '^^^^'J^^^^^ "en% of^h^correspondlng archKecture neutral 
generated by the indicated compiler (rt any). «^ f ° .^'J ^ object class has a corresponding verifiable 

'program (if any). Optiona.v;when^^^^^^^ 

BRIEF DESCRIPTION OF THE DRAWINGS 

depots the structure 0, an architecture neutral program : accordance with a preferred embodiment of the 
" ''TrSr^Tsthestructuredacompi.eda.ch.ecturespecifi.programg^^^^^^ 

invention. 

DESCRIPTION OF THE PREFERRED EMBODIMENTS 

compuler. inoUKles a CPU 110, « «.« " B ccrmurtraB w» es* «» •e™"*^ 
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^\ ovar. rfor 1 02 an ASProgram (architecture specific program) exe- 
120. an ANProgram (architecture neutral P^^^^^^V^^^^^^^^^ 128. a signature generator 130. a 

cuten24. and ANPrograrr. integrity ver.f.er 126 an A^^^^^^^ 9 P P ^^^^^ ^ ^^^^ 3,^,333 , 

M nuslea snd ura<usled obiset class ■epos«<»ie.J «l ai«l ^ reeWOicTO so thai 

5LS,»*ic«ll«us«-»,.sla«lshP|«lJi^-«9«^^^ 

lnth»prelar»a.mbo*msnl>ei™9r«yvsntoblsAmos«^ 

Hows«., sa* «llsnl coWK" «« >»» "J^S^ff^Sa. 122. Tlx. ASLaW M. M .equlrslha 
aconaspoa*9 A5Ur«ua9sartf .xecul«)l.yl^«P^.»^ , ,^„H 

ASP,ogL. .««. « me ASUnW '^^SST^^^SZ^ l»c»»a Ih^^.Wb^den^lWlto 
ASP«,g=™eanp«tom»sl»ll«l=«'"Mbsi»rtf^ 

ritri^trbrsr.srb,T^^^^ — — "^--^ 
-^1-mr.^.ie- ,a«. » A"^- rbr:r:^rr;zr sZfrr 

30 gram eiecuters 124 Of Other Client computers. 

Preparing an Architecture Neutral Program for CompiKng 

Beferr.«toR...an..v.enan.i.inating^ar^^^^^^^^^^^ 

the server computer 104. the OngParty '^"^^^ ANProgram may t,e in an object c.^ 

piling preparer12B and instructrttoprepa^ettie^Wrc^ 9 ^^^^ ^ ^^^^^^ ^ pseudocode 

Contained ^ one of the tn^sted or ^^^J^'-XirrcS 128 to prepare the ANProgram for corn- 

representation of the procedure used by the Al^r^^^^^^ 

r "XSClciS- .he purposes C mis descriptton. n is des,gned to 

jriL^'Kstandablebyariycompu^^^ 

Referring to Figs. 1 and 2 and Tabte 1. the ANPre^ram <»^^ ANProgram 200. This is done to 

verifier 126 and instates it to ^'^^^V f^^^^^^^ of the ANLanguage prior to being sent 

make sure that the ANProgram '^J^J.^;,^^*^^^^ not satisfy the predefined integrity crilena. the 

to the sender computer 104 for compOmg^ If ^^^'^^rt^ANProgram compiling preparer. In response, the AN- 

r.gTmr;rer/ar^^ 

-"^rver.«.eANProgramcode202c^^^^^^^^^ 
vertlier126sendsbacl.apassedresultto.heAr^r^^^^^^^ 

then ca«s the signature generatoriao and .nstnKts^^^^ J J ^^^^^ The signature 

210 that can be verSied to ensure that the ^NPr^^'^^J^^^^^^^^ (^Dop) 21 2 of the ANProgram code 
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45 



co*202.Tben.lheftNProgramcOTPliri9C'Wr«a<n«aBS8iiie8M88lM"»'WfO9tmii«™ 

wilh the specific arguments. 

Compiling an Architecture Neutral Program 

pository 106 via the network <'°^''''^^^\^!^^^^.^^. system 158. a network communications manager 
Thememory154oftheservercomputer104sU^anc^e^^^^ 

160. an ANProgram compiler 162. a signature verrfier l^'^^^^'^^^^e^^^ng system is run on the CPU 150 
1 68. an ANProgram repository 170. and an ASProgr^ T^cl 1 Su ^' r^S^^o c^ issued by a com- 
and controls and coordinates running the programs 1 60-1 68 on the CPU in response loco 

piling party (CompParty) with the ".s^^il^^f^^l^^eives the ANProgram 200 and.instructs the network communica- 
The network communications interface 156 

DigttalSignatureop 210 in the recewed ^NP"^^ 20° ^° ^^^^^ ^^g a lorged sfgnature or the aigParty 

appropriate message. ^.H„To«.Mn do match then the signature verifier 162 sends back a passed 

On the other hand, H the MDqp and the TestlWIDop *> match. ^^^^^^ ANProaram intearity verifier 166. It in- 
50 result to the ANProgram compiler 162 and the ^^N^^^-- 'ISI^jf;^^^^^^^^^ ANProgram 
structs the ANProgram 'ntegrSy verifier to verrty j^^^^^^^^^^^^ ^.^^^^^ 

200. This is done in the same manner «'; '°^,*^^V^MPr^^i?eSs no, satisfy the predefined integrity criteria. 

rheccs;s::=rd?^^^^ 

Tc^np^Sorts the LrJpiling procedure and generates an^^^^ 

However. M the ANProgram code ^2 o, '''^'^^^"SmXp^ ^ 62. The ANProgram 
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OrigParty. Referring now to Figs. 1 -3 and Table 2. the compiler places the ANProgram code 202. the DigitalSignaturGop 
210 and the compiled ASProgram code 302 in an ASProgram 300 that is stored in the ASProgram reposHory 172. 

The ANProgram compiler 162 then calls the signature generator 168 and Instructs it to generate the ANProgram 
compiler's digital signature (DigitalSignaturec) 320 which can be verified to ensure that the ASProgram 300 was com- 
5 piled with the trusted ANProgram compiler. This Is done In a nranner similar to that described earlier for generating the 
DIgitalSlgnatureop. However, in this case, the set of information signed is the ASProgram code and the DigitalSigna- 
tureop. Another predetermined hash function with a corresponding HashFunctionc ID 324 may be used to generate 
the message digest MDc 322 of the set of information to be signed by the DigitalSignaturec, the private encryption 
key of the ANProgram compiler (Compiler's PrivateKey) Is used to encrypt the MDc and the HashFunctbnc ID, and 
10 the identifier of the ANProgram compiler (Compiler's ID) is added In clear text at the end of the encrypted MDt; and 
HashFunctionc- The Compiler's PrivateKey and ID are provided by the ANProgram compiler. 

The ANProgram compiler 1 62 calls the signature generator 1 68 a second time to generate the CompParty's digital 
signature (DigitalSignaturecp) 312. which can be verified by end users to ensure that the ASProgram 300 was gener- 
ated by the trusted CompParty. This is done in a similar manner to that described earlier for generating the DigtialSig- 
IS natureop (in the section discussing preparing an ANProgram tor compiling). However, here the message digest (MDcp) 
314 generated tor the DigitalSignaturecp is generated by computing a predetermined or selected hash function (Hash- 
Functioncp) on the data bits of the ASProgram code, the DigitalSignatuerop and the DigitalSignaturec- Sirhilar to the 
HashFunctlonop. tor purposes of this disclosure, the HashFunciioncp corresponds to the CornpParty since It was used 
for the DigitalSignaturecp of the CompParty. 
20 The signature generator 1 68 then encrypts the MDcp 31 4 and the ID of the HashFunctioncp (HashFunctioncp ID) 

316 with the private encryption key of the CompParty (CompParty's PrivateKey), The signature generator then adds 
the identifier of the CompParty (CompParty's ID) 318 in clear text at the end of the encrypted items 314 and 316 to 
form the DigitalSignaturecp 312. The CompParty's PrivateKey and ID are provided by the CompParty with the user 
interface 152. 

25 After the DigitalSignaturec 320 and the DigitalSignaturecp 312 are generated, the ANProgram compiler 162 ap- 

pends them to the ASProgram code 302, so that the resulting compiled ASProgram file or object has the following 
components in it: 

ANProgram Code, 
30 DigitalSignatureQp, 
ASProgram Code. 
DigitalSignaturec. and 
DigitalSignaturecp 

35 Then, the ANProgram compiler generates a message that the ANProgram 200 has been compiled to form the ASPro- 
gram 300 and is ready to be sent to the OrigParty. ^ 

The CompParty then uses the network communicattons manager 160 to transmit the ASProgram 300 to the Ong- 
Party's client computer 102. The network communications manager does so by retrieving the ASProgram from the 
ASProgram repository 172 in which it is located and provkJes it to the network communications interface 156. The 

40 network communications manager than instructs the networtc communications interface to transmit the ASProgram to 
the OrlgPartys client computer. 

Object and Object Class Creation and Distribution 

45 The transmitted ASProgram 300 is then received by the communicatwns interlace 116 of the OrigParty's client 
computer and instructs the networi^ communications manager 1 20 that this has occurred. In response, the OrigParty 
issues a command with the user interface 252 to Instruct the network communteattons manager to retrieve the received 
ASProgram from the network communicattons interface, causing the network communications manager to place the 
received ASProgram in the untrusted object class repository 142 of the OrigParty's client computer Once this is done, 

so the OrigParty may treat the received ASProgram as a new object class with just one method (i.e. the compiled program 
code), or it may create an object class that includes the ASProgram 300 as well as other ANPrograms and ASPrograms. 

Fig 4 shows a typical object class 400 in accordance with the present invention. The object class may include one 
or more ASPrograms 402 and/or one or more ANPrograms 404. as well as a virtual function table 410. For each 
ASProgram, the virtual function table contains a corresponding identifier (native_ASProgram ID) 412 that Indicates 

55 that it is an ASProgram (i.e.. a native program) that is not in the ANUnguage and a corresponding pointer (Ptr) 414 
to the native program. Similarly, for each ANProgram, the virtual function table contains a corresponding identifier 
(ANProgram ID) 416 and a corresponding pointer 418 to the ANProgram. Every object 420 of this object class includes 
an object header 422 that points to the object class 400. 
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Thus, the OrigParty may create an object 420 and an object class 400 with the ASProgram 300 that was received 
from the server computer 1 04 as one of the ASPrograms 402 in the object class. 

When the OrigParty wishes to distribute to various ExecuteParties an object and object class that includes the 
ASProgram 300 and ANProgram. then the OrigParty issues a command with the user interlace 112 to instruct the 
network communications manager to transmit these items to the client computer 102 of the ExecuteParties. The network 
communications manager does this by retrieving them from the untrusted object class repository 142 in which they are 
located and provides them to the network communrcations Interface 116 with appropriate transmisston instmctions. 
Alternately, the network communications manager of the OrigParty may respond to a request initiated by an Exe- 
cuteParty tor a copy of a specified object class 400. 

Execution of Architecture Neutral Programs and Architecture Specific Programs in an Object Class 



The network communications interface 156 of the client computer 102 receives the transmitted object and object 
class and instructs the network communications manager 160 that this has occurred. In response, the ExecuteParty 
IB issues a command with the user interface 11 2 to instruct the network communications manager to retrieve the received 
object and bbject class from the network communications interface. The network communications manager then stores 
the received object and object class in the untrusted object class repository 142. 

The untrusted object class repository 142 of each client computer 102 contains the objects and their associated 
object classes that are not trusted. These object classes are not trusted because any ANPrograms they include have 
20 not yet had their integrity verified and any ASPrograms they. Include have not had their source verified nor have been 
verified as being compiled from the proper ANProgram. 

The tnjsted object class repository 140 of each client computer contains the objects and their object classes that 
are trusted. These object classes are trusted because any ANPrograms they include may have already had their 
integrity verified by the ANProgram integrity verifier 1 36 and any ASPrograms they contain have been ascertained to 
25 be trustworthy. In fact, some or all the object classes in the trusted object class repository 140 need not have digital 
signatures, because these object classes are trusted and therefore there is no reason to perfomi integrity checks on 
the methods in these object classes. 

It is desirable to have an object class that primarily includes ANPrograms but may also include ASProgranris so 

• that essentially all legitimate tasks can be performed with the object class, as suggested earlier Therefore, the AN- 
Program executer 122 is capable of executing integrity verifiable ANPrograms and calling the ASProgram executer to 
execute integrity non-verifiable ASPrograms that are either (1) in trusted object classes in the trusted object class 
repository 1 40, or (2) that are in untrusted object classes in the untrusted object class repositoiy 1 42 and have verifiable 
DigitalSignatureop. DigrtalSlgnaturecp and DigitalSignaturec information so that essentially all legitimate tasks can be 
performed. In this way. ASPrograms of untrusted object classes that doni have DigitalSignatureop, DigitalSignaturecp 
35 and DigitalSignaturec information or whose digital signatures cannot be verified are prevented from being executed. 
Table 3 contains a pseudocode representation of the execution procedure used by the ANProgram executer. 

Referring to Figs. 1-4 and Table 3, at the client computer 102 of an ExecuteParty (e.g., the OrigParty or another 
party), the ANProgram executer 1 24 may be executing an ANProgram that seeks to call a method in a specified object 
class. The method call is initially handled by the object class loader 136, which detenmines whether or not the object 
40 class has already been toaded. If the object class has already been loaded into the ExecuteParty's user address space 
138, then the ANProgram executer 122 executes the called method if the called method is an ANProgram and the 
ASProgram executer 124 executes the called method if the called method is an ASProgram. 

However, if the object class has not yet been toaded Into the ExecuteParty's address space 138. then the object 
class loader 1 36 loads the object class into the ExecuterPart/s address space and determines whether or not execution 
45 of the called method is to be allowed. For instance, if the object class was loaded from the trusted object class repository 
140. then execution of the called method is permitted and the Execute procedure is called. The Execute procedure 
(see Table 3) calls the ANProgram executer If the called method is an ANProgram. and otherwise calls the ASProgram 
executer 1 24 to execute the called method. 

However, if the object class was toaded from the untrusted object class repository 1 42. the class loader 1 36 ex- 
so amines the object header of the object to determine if its object class includes any ASPrograms. It does so by deter- 
mining if there any native_ASProgram IDs in the virtual function table of the object. 

If there are no ASPrograms in the object class, then the class loader 136 calls the ANProgram integrity verifier 
136 to verify the integrity of the ANPrograms In the object class. This is done in the same manner and for the same 
purpose as was described eariier for verifying the integrity of the ANProgram 200 (in the section discussing compiling 

• an ANProgram). Thus, if the integrity of any of the ANPrograms is not verified, then the ANProgram integrity verifier 
passes back to the class loader a failed result and the class loader aborts the class loading procedure and generates 
an appropriate message indicating this. But. if the ANProgram integrity verifier sends back a passed result indicating 
that all of the ANPrograms of the object class are verified, the class loader enables execution of the called method. 
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If there are any ASPrograms in the object class, then the class loader 136 calls the signature verifier ^1 32 to verify 
the compiler signature DigitalSignalurec and the CompParty signature DigilalSignaturecp. If any of the ASPrograms 
does not include a DigltalSignaturscP and a DigitalSignalurec, the integrity of the ASPrograms sourcp cannot be . 
verified and therefore the signature verifier sends back to the ANProgram executer a failed result. In response, the 
s class loader aborts the object class loading procedure and generates an appropriate message that this has occurred. 
Further tt all of the ASPrograms In the object class do include a DigitaSignaturscp and a DigitalSignaturec, the 
Identities of'the CompParty and the Compiler as indicated n these two digital signatures, are compared wrth the lists 
144 (see Fig 1 ) of known, trusted Compiler Parties and trusted Compilers. If any ot the ASPrograms in the object class 
were compiled by a CompParty or a Compiler not included in the set of known, trusted Compiler Parties and trusted 
10 Compilers the class kading procedure is aborted, and execution of the called method is thereby bkjcked. Similar^r, if 
the ASLanguage identified in any of the ASPrograms does not match the ASLanguage used by the ASProgram Exe- 
cuter 124, the class loading procedure is aborted, u . — ^ 
However if all of the ASPrograms in the object class do include a DigrtalSignaturecp and a DigitalSignaluree, and 
the identified'compParty and Compiler for all the ASPrograms are trusted Compiler Parties and Compilers, and the 
IS ASLanquage used by all the ASPrograms is one used by the ASProgram Executer. then the signature verifier verifies 
these signatures in a similar manner as was described earlier for verifying the DigitalDignatureop (in the section dis- 
cussing compiling the ANProgram 200). However, in this case, the Compiler's and CompPartys public keys are re- 
trieved from the trusted key repository 106 and respectively used to decrypt the MDc and HashFunctiooc ID in the 
DigitalSignaturec and the MDcp and the HashFunctrancp ID in the DigitalSignaturecp. Furthemiore. the test message 
20 digests n-estMDc and TestMDcp) corresponding to the decrypted MDcp and MDc are generated by computing hash 
coles on the data bits of the ASProgram code plus the DigitalSignatureop for the TestMDc and on the same data bits 
plus the DigitalSignaturec for the TestMDcp. according respectively to the HashFunctionc and HashFunctioncp iden- 
tified by the decrypted HashFunctionc ID and HashFunctiongp ID. _,. ,.r^ .un X 
If the DigitalSignaturec and/or the DigitalSignaturecp is not verified (i.e.. MDc#Te8tMDcand/or MDcp # TestMDcp) 
2S for every ASProgram. then the signature verifier 1 36 sends back to the class toader 1 36 a failed result. In response, 
the class toader aborts the class toading procedure and generates an appropriate message that this has o«=""ed. 

However. If the DigitalSignaturec and the DigitalSignaturecp are both verified (i.e.. MDc = TestMDc and MDcp - 
TestMDcp) for every ASProgram. then the ANProgram executer 124 again calls signature verifier 132 to verify the 
OrigPaiVs signatures (DigitaSignatureop) for the ANPrograms from whteh the ASPrograms were compiled. To ver|ty 
the OrigParty digital signatures, the DigitalSignaturecp of each is verified In the same manner as was discussed earlier 
in the sectton concerning compilation of the ANProgram 200. 

If the DigitalSignaturecp of each ol the ANPrograms from which the ASPrograms were compiled is verified, then 
the cbss loader calls the ANProgram integrity verifier to verify the integrity of every ANProgram in the object class and 
the ANPrograms from which the ASPrograms were compiled. This is done in the same manner as was described 
eartier If the integrity of any of these ANPrograms is not verified, then the ANProgram integnty verifier sends back to 
the class toader a failed result, whteh aborts the class loading procedure and generates an appropnate message. 

However if the integrity of each of the ANPrograms is verified, then the ANProgram integrity verifier 126 sends 
back a pass^ result to the dass toader 136. In response, the class toader invokes the ANProgram executer or AS- 
Proqram executer to execute the called method, as appropriate. . . ,^ 

In view of the foregoing, the ExecuterParty is assured that only those untrusted object classes in the untrusted 
repository 1 42 that have integrity verifiable ANPrograms and ASPrograms whose digital signatures can be venfied will 
be k>aded and have their programs executed. 
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Altematlve Embodiments 



45 



Some of the features of the invenlton described above are optional. Thus, those skilled m the art will recognize 
that alternative embodiments exist that don't include these features. .»^ = r,ini.oi 

For example, the ANProgram compiler has been described as generating both a DigitalSignaturecp and a Digital- 
Signaturec respectively for the CompParty and the ANProgram compiler. However, the ANPrc^ram compiler couW be 
so coistructed simply to generate only one of these digital signatures for enabling verifteation of the erther the compiler 
used to compile the ASProgram or the compiling party. ,^ . i^. . »„^ = 

Similarty the program executer has been described as requiring verification of both a DigitalSignaturecp and a 
DigitalSignaturec. However, the program executer could be constructed to require verification of only one of these 
digital signatured and opttenally verify the other digital signature if the ASProgram being venfied inck^es it. Further- 
ss more, the program executer couW be constructed to skip the step of verifying the integrrty ofthe ANProgram conre- 
sponding to each ASProgram. based on the assumptton that the compiling party is trusted and that it is a duty ot me 
c^piling party to verify the integrity of each ANProgram that is compiles into an ASProgram prior to pertomting the 
compilation. 
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When the ExecuterParty is the OrigParty. the ExecuterParty knows that it actually sent the ANProgram 200 to the 
CompParty's server computer 104 to be compiled into the ASProgram 300. In this case, the class loader 1 36 could be 
constructed to not call the signature verifier to verity the DigtialSignaturGop in the ANProgram. Rather, the Executer- 
Party can simply compare the DigtialSlgnatureop in the local copy of the ANProgram with the DigtialSlghatureop in 
s the compiled ASProgram. Additionally, the class loader could be constructed to not call the ANProgram Integrity verifier 
1 26 to verify the integrity of the ANProgram corresponding to a called ASProgram since the integrity of the ANProgram 
would have been checked during the preparation for compiling procedure prior to being sent to the compiling sender 
computer. Altematively, the ANProgram compiling preparer 1 28 could be constructed to not call the ANProgram Integrity 
verifier during the preparation for compiling procedure since its integrity would be checked both by the compiler and 
10 when the class bader calls the ANProgram integrity verifier prior to execution of the corresponding ASProgram. 

TABLE 1 

IS 

Pseudocode Representation of Method of Preparing Architecture 
Neutral Program for Compiling 

20 Procedure: Prepare for Compiling (ANProgram code, OrigParty's PrivateKey, and 
OrigParty's ID) 
{ 

Verify integrity of ANProgram with ANProgram integrity verifier 
If failed result 

{ at>ort and generate failed result message } 
Generate MDqp = HashFunctionop (ANProgram code) 
^ Generate DigitalSignatureop = Encrypt (MDqp + HashFunctionop ID. OrigParty's 

PrivateKey) + ClearText (OrigParty's ID) 
Append DigitalSignatureQp to ANProgram code 
Generate message that ANProgram is prepared for compiling 
3s Return 
) 
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TABLE 2 

Pseudocode Representation of Method of Compiling ANProgram and 
Generating ASProgram 

Procedure: Compile (ANProgram. CompPart/s ID. ASLanguagelD, CompPart/s 
PrivateKey, Compiler's ID. and Compiler's PrivateKey) 
{ 

Retrieve OrigPart/s PublicKey from trusted key reposttory using ClearText 

OrigPart/s ID in DigitalSignatureop 
Decrypt (MD^p + HasfiFunctionop ID in DigitalSignatureop, OrigParty's 

PublicKey) 

Generate TestMDop = HashFunctionop (ANProgram code) using 
HashFunctionop identified by decrypted HashFunctionop ID 

Compare decrypted MDqp and TestMDop 

If decrypted MDqp * TestMDop 
{ 

r DigitalSignatureop of OrigParty not verified •/ 

Generate failed result message 

} 

Else 

{ 

/* DigitalSignatureop of OrigParty has been verified V 
Verify Integrity of ANProgram with ANProgram integrity verifier 
If failed result 

{ 

abort and generate failed result niessage 
} 

Else 

{ 

r ANProgram has been verified V 

Compile ANProgram code into ASLanguage identified by 

ASLanguage ID to generate ASProgram code 
Generate MDc = HashFunclioncs (ASProgram code + 

DigitalSignatureop) 
Generate DigitalSignaturec = Encrypt (MDc + HashFunctionc ID, 

ANProgrom Compiler's PrivateKey) + ClearText 

ANProgram CompBer's ID 
Generate MDcp = HashFunctionop (ASProgram code + 

DigitalSignatureop + DigrtalSignaturec) 
Generate DigitalSignatureop = Encrypt (MD^p + HashFunctionop 

ID, CompPart/s PrivateKey) + ClearText CompParty's ID 
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Generate and Return File or Object containing: 

ANProgram Code, 

DigitalSignatureop, 

ASProgram Code, 

DigitalSignaturec. and 

DigitalSignaturecp 
/* ASProgram has been compiled and generated */ 
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TABLE 3 

Pseudocode Representation of Method of Executing 
Architecture Specific Program 

Procedure: Execute (ObjectClass. Program) 
{ 

If the Program is a verifiable program 

{ Execute Program using the Bytecode Interpreter } 
Else 

{ Execute Program using the compiled program executer } 

} 

Procedure; ClassLoad (ObjectClass, Program) 
{ 

if Object Class has already been loaded into ExecuterPart/s address space 
{ 

Call Execute (ObjectClass, Program) 
Return 

} - 

r The Object Class has not been loaded */ 
Load Object Class into ExecuterPart/s address space 
If Object Class was loaded from Trusted Object Class Repository 
{ 

Call Execute (ObjectClass, Program) 

Return 

} 

/• Object Class was loaded from Untrusted Object Class Repository */ 
if Object Class does not contain any ASPrograms designated as 

native_ASPrograms in Object Header of Object 

{ 

Verify integrity of all ANPrograms of Object Qass with ANProgram Integrity 

verifier 
If failed result 

{ 

Abort with appropriate failed result message 
} 

Else 

r Integrity of all ANPrograms of Object Class have been verified */ 
{ Call Execute (ObjectClass, Program) } 
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Return 
} 

t* Object Class does contain ASPrograms designated as native_ASPrograms In 

Object Header of Object*/ 
If any ASProgram does not contain a DigftalSignaturecp and a DigltalSignaturec 

{ 

t* Compiling Party and Compiler of every ASProgram cannot be verified */ 

Generate appropriate message 

Return 

} 

For each ASProgram in Object Class: 

{ Determine identity of CompParty and Compiler and detemiine 
ASLanguage used by ASPrograrp } 
If identity of CompParty for any ASProgram is not a known, tmsted, Compiling 

Party, or the identity of Compiler is not a known, tmsted Compiler, or the 

identified ASLanguage is not one used by the ASProgram Executer 

{ 

Generate appropriate rnessage 
Return 

) 

For each ASProgram In Object Class: 
{ 

Retrieve CompParty's PublfcKey from tmsted key repository using ClearText 

CompParty's ID in DigHalSignaturecp 
Decrypt (MDcp + HashFunctioHcp ID in DigitalSignaturecp. CompParty's 

PubllcKey) 

Generate TestMDcp = HashFunctioncp (ASProgram code + DigitalSignatureop 
+ DIgitalSignaturec ASProgram) using HashFunctfoncp identified by 
decrypted HashFunctioncp ID 

Compare decrypted MDcp and TestMDcp 

} 

If decrypted MD^p * TestMDcp for any ASProgram 
{ 

r DigitalSignaturecp for every ASProgram has not been verified */ 
Generate appropriate failed result message 
Retum 

) 

/* DigitalSignaturecp for every ASProgram has been verified*/ 
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For each ASProgram in Object Class: 
{ 

Retrieve ANProgram Compiler's PublicKey from trusted key repository usirig 
ClearText ANProgram Compiler's ID In DigitalSignaturec 

Decrypt (MDc + HashFunclionc ID in DigitalSignaturec. ANProgram 
Compiler's PublicKey) 

Generate TestMDc = HashFunclionc (ASProgram code + DigitalSignatureop) 
using HashFunctionc identified by decrypted HashFunctionc ID 

Compare decrypted MD^ and TestMD^ 

} 

If decrypted MDc * TestMDc for any ASProgram 

{ 

r DigitalSignaturec for every ASProgram In Object Class has not been 
verified V 

Generate appropriate failed result message 
Return 

} 

r DigitalSignaturec for every ASProgram in Object Class has been verified */ 
For each ANProgram from which an ASProgram in Object Class was compiled: 

■ " { 

Retrieve OrigPart/s PublicKey from tnisted key repository using ClearText 

OrigPart/s ID in DigitalSignatureop 
Decrypt (MDop + HashFunctionop ID in DigitalSignatureop, OrigPart/s 

PublicKey) 

Generate TestMDop = HashFunctionop (ANProgram code) using 
HashFunctionop identified by decrypted HashFuncBonop ID 
Compare decrypted MDop and TestMDop 
} 

If decrypted MDop * TestMDop for any ANProgram 
{ 

r DigitalSignatureop for every ANProgram from which an ASProgram In 

Object Class was compiled not verified V 
Generate failed result message 
Retum 

} 

r The DigitalSignatureop every ASProgram in Object Class is verified */ 
Verify integrity of ANPrograms in Object class and ANPrograms from which 

ASPrograms In Object aass were compiled with ANProgram integrity verifier 
If failed result 

{ 
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Generate failed result message 

Return ^ 

} • ' 

I* Integrity of all ANPrograms in Object class and all ANPrograms from which 

ASPrograms in Object Class were compiled have been verified */ 
Call Execute (ObjectClass, Program) 
} 



Claims 

1 . A computer comprising: 

a program integrity verifier tliat verifies tliat programs written in an architecture neutrai language satisfy pre- 
defined program integrity criteria; 

a digital signature verifier that verifies the digital signatures of originating parties of programs that are contained 
in the programs; 

an untrusted object class repository that stores untrusted object classes; 
a trusted object class repository that stores trusted object classes; 

said object classes each including at least one program, each program comprising a program selected from 

the group consisting of (A) architecture neutral programs written in the architecture neutral language and (B) 

architecture specific programs written in an architecture specific language whose integrity cannot be verified 

by the integrity verifier; 

an architecture specific program executer; 

an architecture neutral program executer; 

a user address space; and 

a class loader that bads a specified one of said object classes into the user address space for execution when 
execution of any program in the one object class is requested, said class loader including program security 
logic for preventing the loading of any requested object class, other than object classes in said tmsted object 
class repository, that includes at least one architecture specific program unless every architecture specific 
program in the requested object class includes a digital signature and said digital signature is successfully 
verified by said digital signature verifier. 

2. The computer of claim 1 , said class loader includes verifier logic for Invoking said program integrity verifier to verify 
the integrity of every architecture neutral program in the requested object class when the requested object class 
is not stored in said trusted object class repository and includes at least one architecture neutral program; 

said program security logic further preventing the loading of said any requested object class other than object 
classes in said tmsted object class repository when the requested object class includes at least one architecture 
neutral program whose Integrity Is not verified by said program Integrity verifier. 

3. The computer of claim 1 , 

each said digital signature associated with one of said architecture specific programs including a signing party 
Identifier and an encrypted message, said encrypted message including a message digest of the architecture 
specific program generated using a message digest function wherein said encrypted message has been en- 
crypted using a private encryption key associated with said identified signing party; and 
said digital signature verifier including bgic for processing a specified digital signature by obtaining a public 
key associated with the signing party identified by said signing party identifier, decrypting the encrypted mes- 
sage of said digital signature with said public key so as generate a decrypted message digest, generating a 
test message digest by executing said message digest function on the architecture specific program associated 
with said digital signature, comparing said test message digest with said decrypted message digest, and Is- 
suing a failure signal if said decrypted message digest and test message digest do not match. 
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The computer of claim 1 , 

said program security logic further for preventing the loading of any requested object class, other than object 
classes in said trusted object class repository, that includes at least one architecture specific program unless 
every architecture specific program in the requested object class includes twodigital signatures and said digital 
signatures are both successfully verified by said digital signature verifier; 

each said digital signature associated with one of said architecture specific programs including a signing party 
identifier and an encrypted message, said encrypted message including a message generated by a predefined 
procedure, wherein said encrypted message has been encrypted using a private encryption key associated 
with said identified signing party; 

said digital signature verifier including logic for processing a specified digital signature by obtaining a public 
key associated with the signing party identified by said signing party identifier, decrypting the encrypted mes- 
sage of said digital signature with said public key so as generate a decrypted message, generating a test 
message by executing said predefined procedure on the architecture specific program assoc'ated with said 
digital signature, comparing said test message with said decrypted message, and issuing a failure signal" if 
said decrypted message digest and test message digest do not match; and 

said program security logic preventing loading of the requested object class, other than object classes In sard 
trusted object class repository, unless every architecture specific program in the requested object class in- 
cludes a first digital signature for which the signing party Is a member of a first group of trusted parties, and 
includes a second digital signature for which the sigriing party is a member of a second group of trusted parties. 

The computer of claim 1 , 

said program security logic preventing loading of the requested object class, other than object classes in 
said trusted object class repository, unless every architecture specific program in the requested object class in- 
cludes a message digest for an associated architecture neutral program, and said message digest matches a test 
message digest generated by said program security logic by performing a predefined message digest procedure 
on said associated architecture neutral program. 

A method of operating a computer system, comprising the steps of: 

storing untrusted object classes in an untrusted object class repository; 
storing trusted object classes in a trusted object class repository; 

said object classes each including at least one program, each program comprising a program selected from 
the group consisting of (A) architecture neutral programs written in an architecture neutral language and (B) 
architecture specific programs written in an architecture spiecific language; 

when execution of any program in the one object class is requested, bading the requested object class into 
a user address space for executbn unless loading of the requested object class is prevented by a security 
violation, including preventing the toading of any requested object class, other than object classes in said 
trusted object class repository, that includes at least one architecture specific program unless every architec- 
ture specific program in the requested object class includes a digital signature and said digital signature is 
successfully verified by said digital signature verifier. 

The method of claim 6, said object class loading step including (A) verifying the integrity of every architecture 
neutral program In the requested object class when the requested object class is not stored in said trusted object 
class repository and includes at least one architecture neutral program, and (B) and preventing the loading of the 
requested object class, unless the requested object class is In said trusted object class repository, when the re- 
quested object class includes at least one architecture neutral program whose Integrity is not verified. 

The method of claim 6, 

each said digital signature associated with one of said architecture specific programs including a signing party 
identifier and an encrypted message, said encrypted message including a message digest of the architecture 
specific program generated using a message digest function wherein said encrypted message has been en- 
crypted using a private encryption key associated with said identified signing party; and 
said object class loading step including processing a specified digital signature by obtaining a public key as- 
sociated with the signing party identified by said signing party kientifier. decrypting the encrypted message of 
said digital signature wrth said public key so as generate a decrypted message digest, generating a test mes- 
sage digest by executing said message digest function on the architecture specific program associated with 
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said digital signature, comparing said test message digest with said decrypted message digest, and issuing 
a failure signal if said decrypted message digest and test message digest do not match. 

9. The method of claim 6. 

object class loading step including preventing the loading of any requested object class, other than object 
classes In said trusted object class repository, that includes at least one architecture specific program unless 
every architecture specific program in the requested object class includes two digital signatures and said digital 
signatures are both successfully verified by said digital signature verifier. 

each said digital signature associated with one of said architecture specific programs including a signing party 
identifier and an encrypted message, said encrypted message Including a message generated by a predefined 
procedure, wherein said encrypted message has been encrypted using a private encryption key associated 
with said identified signing party; 

said object class loading step including processing a specified digital signature by obtaining a public key as- 
sociated with the signing party identified by said signing party Identifier, decrypting the encrypted message of 
said digital signature with said public key so as generate a decrypted message, generating a test message 
by executing said predefined procedure on the architecture specific program associated with said digital sig- 
nature, comparing said test message with said decrypted message, and issuing a failure signal if said decrypt- 
ed message digest and test message digest do not match. 

said object class k>ading step further Including preiVentIng loading of the requested object class, other than 
object classes in said trusted object class repository, unless every architecture specific program in the request- 
ed object class includes a first digital signature for which the signing party is a member of a first group of 
trusted parties, and includes a second digital signature for which the signing party is a member of a second 
group of trusted parties. 

10. The method of claim 6, 

said object class loading step including preventing loading of the requested object class, other than object 
classes in said trusted object class repository, unless every architecture specific program in the requested object 
class includes a message digest for an associated architecture neutral program, and said message digest matches 
a test message digest generated by said program security logic by performing a predefined message digest pro- 
cedure on said associated architecture neutral program. 

11. A memory for storing data programs being executed on a data processing system, said memory comprising: 

a program integrity verifier that verifies that programs written in an architecture neutral language satisfy pre- 
defined program integrity criteria; 

a digital signature verifier that verifies the digital signatures of originating parties of programs that are contained 
in the programs; 

an untrusted object class repository that stores untrusted object classes; 
a trusted object class reposito^ that stores trusted object classes; 

said object classes each including at least one program, each program comprising a program selected from 

the group consisting of (A) architecture neutral programs written in the architecture neutral language and (B) 

architecture specific programs written in an architecture specific language whose Integrity cannot be verified 

by the integrity verifier; 

an architecture specific program executer; 

an architecture neutral program executer; and 

a class loader that loads a specified one of said object classes Into a user address space for execution when 
execution of any program in the one object class is requested, said class loader including program security 
instructions for preventing the loading of any requested object class, other than object classes in said trusted 
object class repository, that includes at least one architecture specific program unless every architecture spe- 
cific program in the requested object class includes a digital signature and sakd digital signature is successfully 
verified by said digital signature verifier. 

12. The mennory of claim 11, said class loader includes verifier instructions for invoking said program integrity verifier 
to verify the integrity of every architecture neutral program in the requested object class when the requested dbject 
class is not stored in said trusted object class repository and includes at least one architecture neutral program; 

said program security instructions further preventing the loading of said any requested object class other 
than object classes in said trusted object class repository when the requested object class includes at least one 
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(57) A computer system includes a program execut- 
erthat executes verifiable architecture neutral programs 
and a class loader that prohibits the loading and execu- 
tion of non-verifiable programs unless (A) the non-veri- 
fiable program resides in a trusted repository of such 
programs, or (B) the non-verifiable program is indirectly 
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fiable program that proves the program was produced 
by a trusted source. In the preferred embodiment, veri- 
fiable architecture neutral programs are Java bytecode 
programs whose integrity is verified using a Java byte- 
code program verifier. The non-verifiable programs are 
generally architecture specific compiled programs gen- 
erated with the assistance of a compiler. Each architec- 
ture specific program typically includes two signatures, 
including one by the compiling party and one by the 



compiler. Each digital signature includes a signing party 
Identifier and an encrypted message. The encrypted 
message kicludes a message generated by a prede- 
fined procedure, and is encrypted using a private en- 
cryption key associated with the signing party A digital 
signature verifier used by the class loader includes logic 
for processing each digital signature by obtaining a pub- 
lic key associated with the signing party, decrypting the 
encrypted message of the digital signature with that 
public key so as generate a decrypted message, gen- 
erating a test message by executing the predefined pro- 
cedure on the architecture specific program associated 
with the digital signature, comparing the test message 
with the decrypted message, and issuing a failure signal 
if the decrypted message digest and test message di- 
gest do not match. 
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